less_systemd_gnulinuxfandomcom-20200213-history
Packaging software
This page is in help of those wishing to help out with the software packaging proccess. Things you should know before getting started You will have to keep in mind the following hints before diving into packaging: *packages names are different, they follow the closely the LFS and BLFS books names *since GTK3 is not considered stable enough for production use and none of the official packages supports it there are some exceptional names such as gdk-pixbuff and vte - no such prefix as "2" or "3" like in Arch Linux *some packages are bundled in a multi-package, xorg-libraries is a good example *packages from Core shouldn't depend on packages from the Extra repository Toolchain build order #linux-api-headers (part of the linux package) #glibc #binutils #gcc #binutils #glibc PKGBUILDs *prefer xz and bz2 over other tarballs for sources *use sha256sums for sources verification *drop all documents except man pages and in some cases example files *if package offers check via test suite use it *always use the proper license shipped with the source(s) tarball, if in doubt consult the license package *install packages from base to / not /usr needed for system initialization : glibc : ncurses : readline : bash : coreutils* : zlib : e2fsprogs : lvm2 : findutils : gawk : grep : hwids : udev : syvinit : initscripts NOTE: compat with /usr need to be done by symlinking the binaries from /bin and /sbin to /usr/bin and /usr/sbin because some scripts use hardcoded paths Quircks *glibc supports Linux Kernel version greater or equal to 3.2.0 only *rare cases of packages failing to link against the udev fork in use (e.g. chormium), workaround is to use eudev-git Tools of the trade The tools used to package and provide software packages are lsd-tools, or LSDT. Its sources are located at https://bitbucket.org/smil3y/lsd-tools. LSDT is a set of scripts to assist in creating chroot environment, building packages in chroot, updating repository databases and more. It is part of the devel packages group which you should have installed before trying to compile any piece of software and package it. The packages sources can be obtained from https://bitbucket.org/smil3y/pkgbuilds. Getting your hands dirty Building from the official package files First you will need the package files sources, PKGBUILDs that is. To obtain a fresh copy issue the following in Terminal: git clone --depth=1 https://smil3y@bitbucket.org/smil3y/pkgbuilds.git Or, if you already have a copy of the sources, just update them: cd pkgbuilds git pull origin master A wrapper scripts is provided to easy the things. It will create a clean chroot environment, build packages in it, copy them into the apropariate repository directory and update the repository database for you. To compile a package just issue the following as root: cd pkgbuilds ./build.sh core/base/bash and all the dirty work will be done for you! Marvelous isn't it? Porting new packages Porting new packages can be hard for new-commers but essentially you should just keep track of the dependencies packages, look how the LSD GNU/Linux packages are packaged and what they provide as the multi-packages ship different packages all-together. There are frozen ports package files gathered in the package files tgit repository which are not finished and are unlikely to be maintained as official packages, lack a few build time dependencies (makedepends) and/or have limmited functionality compared to those shipped in the Arch Linux repositories because they are not linked against that many packages (e.g. mplayer2 doesn't link against libbluray, yet it plays fomats such as MPEG-TS, BDAV and other formats) and don't recieve upgrades and patches but they compile, install and work as intented mostly without a hitch. You can pick up on them and just sanitize them as described bellow, put them in a repository and ship them ready for use. If you have the guts to do that you can contact the contributors and make a community maintained repository to extend upon the base of LSD GNU/Linux. The easiest way to port new packages is download package files from Arch Linux and adjust them properly. First step is to go to https://www.archlinux.org/packages/ and search for the package you want to port. When/if found click on the name of the package in the Name collumn. On the right you will see Package Actions container and in it Source Files, clicking on it will take you to the package files. You can grab them with curl but they have to be in raw format so you have to click on the individual package files, and when you see something like this: blob: 3201305b5f652dcfc73badabc555490e84620707 (plain) click on the plain link. Now you can grab the URL from the URL bar of your browser of choice and download the file: curl > After downloading all of the package files you should adjust the Maintainer and, optional, the Contributors if there are any. Also make sure you check the License the software uses directly from the sources tarballs, look for files named COPYING, LICENSE, README, etc. and read them carefully as some softwares use multiple Licenses. When done with that update the checksums to sha256sums. Next satisfy the dependencies by searching what is available in the repositories and what the package needs, porting more packages to saticfy them may be needed too. Check if the packages offers test suite, usually a good place for this are the LFS and BLFS books, if yes add check() function if not present. Finally build the package and test how it works, if all goes well you can send your port to the package and/or repository maintainers, just take a look at the Contributors page. Tips and tricks Tracking dependencies If you find that a package fails to compile with a message like this: *** The required package exo-1 was not found on your system. *** Please install exo-1 (atleast version 0.7.1) or adjust *** the PKG_CONFIG_PATH environment variable if you *** installed the package in a nonstandard prefix so that *** pkg-config is able to find it. even tought you know that the package is installed you can use this: pkg-config --cflags exo-1 and will get something like this: Package xproto was not found in the pkg-config search path. Perhaps you should add the directory containing `xproto.pc' to the PKG_CONFIG_PATH environment variable Package 'xproto', required by 'xau', not found In this case the xorg-protocol-headers package is missing which provides xproto. Adding xorg-protocol-headers to the makedepends array will fix that. If everything is fine you will get something like the following output: -pthread -I/usr/include/exo-1 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng15 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng15 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/xfce4 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include by running a pkg-config check again. Testing dependencies Testing for missing library dependencies is very simple, using ldd (shared library dependencies printer) provided by glibc: ldd $(which xfce4-appfinder) | grep "not found" If there some output that means that the package will not function as it should or even segmentation fault which shouldn't happen. Editing the PKGBUILD of the package you are testing to make sure the dependencies are satisfied will fix the issue. Checking for conf files Config files of packages need to be backed up on upgrade and since Pacman has the this feature we should make use of it. To search for configs you can use the following command: pacman -Qlq | grep conf The output of this command should be only config files and those should go to the backup array in the PKGBUILD of the package. If you get lots of output you can strip it a little bit: pacman -Qlq | grep conf | grep etc or: pacman -Ql | grep conf | grep -v -e pkgconfig -e locale -e bin -e sbin But keep in mind that conf files should be backed up only if there is no way to override the behavior of the main conf file except editing it, i.e. there is no /etc/.d. Checking for manual pages Shipping manual pages is important but sometimes they are not generated because libxml2, docbook-xml, docbook-xsl, asciidoc or other package is missing. To make sure that manual pages are installed you can use this: pacman -Qlq | grep share/man If there is not output you should check if the packaged software has the options to generate manual pages, if there is but they are not generated at compile time make sure that the dependencies are satisfied and optionally check for "--enable-doc" or "--enable-man" in the configure script output of the software. Category:First steps Category:Development